CLEARWATER: CA-96541/SCTX-1188: Fix race condition when creating metrics for VLAN PI... #1084
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… PIFs This fixes a race condition between the thread that copies bonds and VLANs from the master when a new slave joins the pool, and the thread that creates/updates the PIF_metrics (the "monitor thread"). Or in fact a race between anything that creates a bond and very soon after that a VLAN on top of it. Since XCP1.6/XS6.1, VLANs no longer have their own PIF_metrics. Rather, they point to the PIF_metrics of the underlying PIF, which can be either a physical PIF (e.g. for eth0), or a bond PIF. Therefore, the carrier of a VLAN PIF is the same as the carrier of the underlying PIF. When a physical PIF or bond PIF is created, it does not immediately have PIF_metrics (PIF.metrics = "OpaqueRef:NULL"). The PIF_metrics object is created and assigned to the PIF by the monitor thread a short while after that. If you create a VLAN before the PIF_metrics have been created, the PIF.metrics field from the underlying PIF will still be copied, which is "OpaqueRef:NULL". This will never get updated, because the monitor thread ignores VLANs. The fix is simply to immediately create an (empty) metrics object when creating a bond. Signed-off-by: Rob Hoes <rob.hoes@citrix.com>
ghost
assigned
malcolmcrossley
pushed a commit
that referenced
this pull request
Apr 6, 2013
CLEARWATER: CA-96541/SCTX-1188: Fix race condition when creating metrics for VLAN PI...
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
...Fs
This fixes a race condition between the thread that copies bonds and VLANs from
the master when a new slave joins the pool, and the thread that creates/updates
the PIF_metrics (the "monitor thread"). Or in fact a race between anything that
creates a bond and very soon after that a VLAN on top of it.
Since XCP1.6/XS6.1, VLANs no longer have their own PIF_metrics. Rather, they point
to the PIF_metrics of the underlying PIF, which can be either a physical PIF
(e.g. for eth0), or a bond PIF. Therefore, the carrier of a VLAN PIF is the same
as the carrier of the underlying PIF.
When a physical PIF or bond PIF is created, it does not immediately have
PIF_metrics (PIF.metrics = "OpaqueRef:NULL"). The PIF_metrics object is created
and assigned to the PIF by the monitor thread a short while after that. If you
create a VLAN before the PIF_metrics have been created, the PIF.metrics field from
the underlying PIF will still be copied, which is "OpaqueRef:NULL". This will never
get updated, because the monitor thread ignores VLANs.
The fix is simply to immediately create an (empty) metrics object when creating a
bond.
Duplicate of #1083